1. Field of the Invention
The present invention relates to a program creation apparatus for use in a software development system to be built in an apparatus.
2. Description of the Prior Art
These years, various electronic apparatuses are controlled by a built-in microprocessor and software. Moreover, various electronic apparatuses have been developed to be connected to a telephone line or the like for communication in a network Furthermore, there has also been developed an apparatus having a function for transmitting and receiving a control software module through a network.
For software to be built in such an apparatus, it is considered to support communication and a software module transmission and reception from the level of an operating system (OS).
In an ordinary OS to be built in, a system module is delivered as a library. Some files depending on hardware may be provided as source files.
When extending a program function in a program development procedure, an additional library is created. Because a system file is a library, it is linked together with a program developed by a user. For replacing a module during a program execution, an additional module is read externally to the linked system program and the user program.
Here, explanation will be given on a software development system for an ordinary software to be built in. The explanation will be given, assuming a case using the C language as the programming language, but the basic procedure can also be applied to a case using other languages.
FIG. 1 shows an example of software development system for an ordinary built-in OS.
A header file 10 and a source file 11 are prepared by a user. These files may be created by the user or may be provided by a software development system.
A compile information 12 is an optional information for specifying a compile form to a compiler 13 such as a CPU type and optimization specification.
A compile processing block 14 compiles the source file 11 to create an object file 15, using a compiler 13 appropriate for a target hardware, a compile information 12, and a header file 10.
A library file 16 may be a library provided by a software developement system or created in advance by a user.
A link information 17 is an optional information for specifying a link form to a linker 18.
A link processing block 19 links a plurality of object files 15 to create a single execution-formatted file 20, using a linker 18 appropriate for a target hardware, the linke information 17, and the library file 16.
Here, explanation will be given on a software development procedure for an ordinary built-in software.
FIG. 2 shows an example of the software development procedure for an ordinary built-in OS.
A system library 21 is a library file including a program for implementing a function of the OS.
A system source file 22 is a file for providing the OS function implementing program as a source code. This system source file 22 is compiled by the compile processing block 14 so as to create an object file 23. It should be noted that such a system source file 22 is usually delivered for a hardware-depending portion.
A user source file 24 is a source file created for apparatus control by a user. This user source file 24 is compiled to create a compile file 25. The system library 21, the object file 23, and the object file 25 are linked in the link processing block 19 so as to create a single execution-formatted file 20.
FIG. 3 shows an internal structure of an execution-formatted file as an example of the aforementioned conventional execution-formatted file.
An internal structure information 61 is located at a head of the execution-formatted file 20 and contains an information for identifying a following content and its length. By analyzing this internal structure information 61, it is possible to extract a necessary information from the following part.
A text section 62, as shown in FIG. 2, is a program code collected from the system library 21, the object file 23, and the object file 25, and combined.
An initialization section 63 is an initial value data of variables which have been collected and combined in the same way.
An initialization-free (not required) data section 64 is a data area for variables having no initial values determined, which have been collected and combined in the same way.
A debug information section 65 is an area for saving a symbol information such as a variable name for program debug. In a built-in software, it is usual that the linker is specified to delete this debug information section 65 at a final stage.
As a format of such an execution-formatted file 20, for example, ELF (Executable Linking Format) and COFF (Common Object File Format) are known.
Moreover, the following can be exemplified as the OS.
In an ordinary computer OS, a system module is delivered mainly as an executable file format. Moreover, in some OS, a source file is similarly delivered, which is compiled to be converted into an executable file format.
When extending a program function during a program development procedure, a source file formatted as an executable file is added. Alternatively, an additional file for extending the program function is provided in a library format such as DLL (Dynamic Link Library) which is executed via an OS during a user program execution.
If the system file is an executable file, the system file is read into a memory via the OS when a user requires a program.
When replacing a module during a program execution, the OS reads a new fle into memory, discarding the memory content corresponding to a conventional file.
Such a built-in software development system based on an ordinary computer OS is also provided.
Moreover, a so-called Java is used as a programming language. In this case, the system module is delivered mainly as an executable file format or byte code (intermediate code).
The byte code is executed as it is directly by an interpreter or converted via a compiler into an executable file format.
The executable file format has an internal structure similar to the one shown in FIG. 3, for example, where one file has only one execution program. It should be noted that a plurality of execution programs may be compressed/combined into a single file but in this case also, the file format shown in FIG. 3 is maintained.
When extending the program function during a program development, a byte code file is added.
Moreover, when replacing a module during a program execution, the OS reads a new file into a memory, discarding the memory content corresponding to a conventional file.
Such a software development system is provided for a built-in type in an apparatus.
In the aforementioned conventional operating system (OS), if a replacement of a module is considered in implementation into an apparatus, there arise following problems.
(1) In an ordinary OS to be built in, a user module and a system module are linked into a single execution-formatted file and accordingly, it is difficult to dele a particular module during execution of the execution-formatted file. For example, a text section containing a program code of a system module is linked to a text section of a user module, and they cannot be separated from each other.
(2) In an ordinary computer OS, management of a replacement module is carried out in a file system, and reading into a memory and deletion from the memory is carried out when required. In this method, however, the file system should be provided by a kernel, which in turn increases the kernel size and the memory size. This is not preferable in a built-in system having a strict restriction on the emory size.
(3) If each of the modules is in the execution format outputted from an ordinary compiler, the file size is considerably large, requiring more capacity then necessary when stored in a ROM (read only memory). For example, a file has an area filled with 0 for a data which need not be initialized with a particular value during an execution. This area is necessary during an execution but can be deleted while the file is preserved. Upon execution, it is possible to allocate an area of the same size initialized by 0. A part of ROM size is occupied by such an unnecessary information. This also brings about a cost increase when a number of files are required.
Moreover, in a conventional built-in software development system, following problems are caused if consideration is taken on the implementation into an apparatus and replacement of some modules afterward.
(4) In an ordinary built-in operating system development system, it is impossible to create a program in a format which enables to delete some of the modules.
(5) When a number of modules are present, it is necessary to read the respective modules into a memory during a built-in software development. This takes a considerable time if the number of execution-formatted files is large.
(6) An area which can be deleted and reconstructed upon execution is not deleted from an execution-formatted file which is outputted from a compiler. Accordingly, each module requires a large file size.
(7) When an additional module is provided in a library format, it is difficult to create a file in such a module that some of the modules can be deleted during execution. If the additional module is provided as a source file, it is possible to create a file in such a format that some of he modules can be replaced during execution. However, this depends on a user who should compile the system source file appropriately.